Fraud in eCommerce transactions has become a significant problem. Credit card issuers have created the “surrogate card number” model in an attempt to address this problem. According to this model, a “one time” credit card number is generated by a credit card issuer and automatically mapped back (by the issuer system) to the original card number during any subsequent authorisation, capture or refund event. The original card number is, therefore, never exposed and in the event the “one time” number is compromised (e.g. a hacker successfully penetrates the merchant's system) the fraud risk is mitigated as the “one time” number is deactivated for further purchase activity once the first authorisation event is processed.
While this model represents a significant improvement in online fraud management and has helped to establish consumer confidence in online commerce, it remains vulnerable to the threat of identity theft (commonly referred to as “phishing”). A variety of sophisticated techniques, including social engineering, are employed by fraudsters to discover consumer information (e.g. User Ids, passwords etc.) to enable them to perform seemingly valid transactions for fraudulent purposes. For example, in the “one time” card model, the fraudster would attempt to discover the consumer's password to enable the fraudster to request a valid “one time” credit card number to purchase goods online and have them shipped to a different address. Customers subsequently repudiate the transaction leaving the issuer in the position of adjudicator with consequential financial loss or reduction in customer satisfaction levels.
In essence the point of attack is starting to shift away from merchant's systems back to the issuer's systems. While the “surrogate card number” model is principally designed to effectively address merchant vulnerabilities, further expansion of the concept is needed to consider issuer side threats and vulnerabilities.
Likewise, fraud is a significant problem in money transfer transactions. Under typical practice, a sender visits an “agent” (i.e., agent of a money transfer system operator, such as Western Union of Englewood, Colo.) location to specify payee details (name, destination country and test question, if applicable) and pay applicable fees and principal amount to be transferred. The agent receipts the transaction details into a money transmission system and receives a Money Transfer Control Number (“MTCN”) that uniquely references the transaction. The agent provides the MTCN to the sender. The sender advises the recipient (Payee) through independent means (e.g. phone call or SMS) of the transfer's availability for collection and the MTCN. The payee visits an agent location, and supplies the MTCN, appropriate identification and correct response to the test question (if applicable). The agent pays out the principal amount on successful completion of verification checks. Some of the foregoing steps may be performed by Internet-based means.
This model is vulnerable to a number of attacks. For example, a paying agent may collude with a fraudster and pay out funds without complying with local verification procedures. An unrelated agent in the paying country may also retrieve the transaction details from the money transfer software using limited search criteria and enable an accomplice to proceed with collection at a separate location in the expected payout country. Or, a number of fraudulently inclined individuals may present themselves simultaneously at different agent locations in the destination country of a transfer and all receive payout before the money transfer system is able to detect the problem.
Hence, a more robust payee authentication method is required at point of payout to secure the process from these attacks.